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NETWORK INDEPENDENT SAFETY PROTOCOL FOR INDUSTRIAL CONTROLLER 



CROSS-REFERENCE TO RELATED APPLICATIONS 

This application claims the benefit of provisional apphcation 60/171,439 filed on 
5 December 22, 1999. 

STATEMENT REGARDING FEDERALLY 
SPONSORED RESEARCH OR DEVELOPMENT 

BACKGROUND OF THE INVENTION 

1 0 The present invention relates to industrial controllers used for real-time control of 

industrial processes, and in particular to high-reliability industrial controllers appropriate for 
use in devices intended to protect human life and health. "High reliability" refers generally to 
systems that guard against the propagation of erroneous data or signals by detecting error or 
fault conditions and signaling their occurrence and/or entering into a predetermined fault 

.1 5 state. High reliability systems may be distinguished from high availability systems, however, 
the present invention may be useful in both such systems and therefore, as used herein, high 
reliability should not be considered to exclude high availability systems. 

Industrial controllers are special purpose computers used in controlling industrial 
processes. Under the direction of a stored control program, an industrial controller examines 

2 0 a series of inputs reflecting the status of the controlled process and changes a series of outputs 
controlling the industrial process. The inputs and outputs may be binary, that is, on or off, or 
analog, providing a value within a continuous range. The inputs may be obtained from 
sensors attached to the controlled equipment and the outputs may be signals to actuators on 
the controlled equipment. 

2 5 "Safety systems" are systems intended to ensure the safety of humans working in the 

environment of an industrial process. Such systems may include the electronics associated 
with emergency stop buttons, interlock switches and machine lockouts. Traditionally, safety 
systems have been implemented by a set of circuits wholly separate from the industrial 
control system used to control the industrial process with which the safety system is 

30 associated. Such safety systems are "hard-wired" from switches and relays, some of which 
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may be specialized "safety relays" allowing comparison of redundant signals and providing 
internal checking of conditions such as welded or stuck contacts. Safety systems may use 
switches with dual contacts providing an early indication of contact failure, and multiple 
contacts may be wired to actuators so that the actuators are energized only if multiple 
contacts close. 

Hard- wired safety systems have proven inadequate, as the complexity of industrial 
processes has increased. This is in part because of the cost of installing and wiring relays and 
in part because of the difficulty of troubleshooting and maintaining the "program" 
implemented by the safety system in which the logic can only be changed by rewiring 
physical relays and switches. 

For this reason, there is considerable interest in implementing safety systems using 
industrial controllers. Such controllers are easier to program and have reduced installation 
costs because of their use of a high-speed serial communication network ehminating long 
runs of point-to-point wiring. 

Unfortimately, high-speed serial communication networks commonly used in 
industrial control are not sufficiently reliable for safety systems. For this reason, efforts have 
been undertaken to develop a "safety network" being a high-speed serial communication 
network providing greater certainty in the transmission of data. Currently proposed safety 
networks are incompatible with the protocols widely used in industrial control. Accordingly, 
if these new safety networks are adopted, existing industrial controller hardware and standard 
technologies may be unusable, imposing high costs on existing and new factories. Such costs 
may detrimentally postpone wide scale adoption of advanced safety technology. 

What is needed is a safety network that is compatible with conventional industrial 
controller networks and components. Ideally such a safety network would work with a wide 
variety of different standard communication protocols and would allow the mixing of 
standard industrial control components and safety system components without compromising 
rehab ility. 

BRIEF SUMMARY OF THE INVENTION 
The present invention provides a network-independent, high-reliability 
communications system by imposing two levels of protocol on data being transmitted over 
the network. The first level of protocol provides the high-reliability necessary for a safety 
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system while the second level of protocol encapsulates the protocol of the safety system 
allowing it to be transmitted on a standard network. 

The safety network of the present invention is compatible with a wide variety of 
standard networks and standard network hardware and also allows safety and non-safety 
components to be intermixed through the medium of the standard network. The safety 
protocol adds error detection data to transmitted data, all of which is treated as data by the 
standard network. The safety protocol also adds timing requirements for message 
transmission that ensure reliable transmission but that can remain invisible to the protocol of 
the standard network. 

Specifically the present invention provides a network-independent, high-reliability 
communication system for an industrial controller making use of a standard serial 
communication network. The communication system includes a first I/O conmiunication 
circuit receiving I/O data for control of an industrial process. This I/O data may be input or 
output data and the circuit may be at an industrial controller or at its I/O module. The I/O 
data is received by a first network-independent protocol circuit which formats it for 
transmission under a network-independent protocol to produce high-reliability formatted 
data, formatted so as to reduce errors in transmission. The high-reliability formatted data is 
received by a standard network protocol circuit, which further formats it for transmission 
under a protocol of the standard serial communication network. In this way, it produces 
doubly-formatted data for transmission on the standard serial communication network. The 
formatting of the protocol for the standard serial communication network also reduces errors 
in transmission. After transmission over a standard serial communication network, the 
doubly-formatted data is received by a second standard network protocol circuit, which 
extracts the high-reliability formatted data according to the protocol of the standard serial 
communication network. The data is then received by a second network-independent 
protocol circuit extracting fi-om the high-reliability formatted data, the original I/O data. A 
second I/O communication circuit receives the I/O data for control of the industrial process. 

Thus it is one object of the invention to provide for a high-reliability communication 
system that may nevertheless use the standard circuitry and protocols of common, well- 
developed and commercially available serial communication networks. The safety 
formatting is embedded in the standard protocol of the serial network, which treats the 
formatted safety data as normal data to be transmitted. 



The first network-independent protocol circuit may format the I/O data by adding 
error detection methods selected from the group consisting of cyclic redundancy codes 
related to the I/O data and sequence counts related to the local order of transmission of the 
I/O data with respect to other I/O data being transmitted. 

Thus it is another object of the invention to provide for high-reliability 
communication for safety systems regardless of the presence or absence of error reduction 
data in the protocol of the standard serial network. 

The second network-independent protocol circuit may further generate an 
acknowledgement message upon receipt of the I/O data formatted under the network- 
independent protocol to produce high-reliability formatted acknowledgement data. The 
second standard network protocol circuit may receive the high-reliability formatted 
acknowledgement data and further formats it for transmission under the protocol of the 
standard serial communication network to produce doubly-formatted acknowledgement data 
for transmission on the standard serial communication network. The first standard network 
protocol circuit may receive the doubly-formatted acknowledgement data from the standard 
serial communication network and extract the high-reliability formatted acknowledgement 
data according to the protocol of the standard serial communication network. Finally, the 
first network-independent protocol circuit may receive the high-reliability formatted 
acknowledgement data to detect transmission errors. 

Thus it is another object of the invention to provide for the detection of lost messages 
regardless of this capability in the standard serial network. The timing protocol may operate 
invisibly to the standard serial network as implemented at a higher level. By providing a 
closed loop of transmission, the present invention can detect errors not only in the 
transmission media but also in the processing circuitry and other components such as 
processors within that communications loop. Errors introduced from any one or all of these 
sources will be termed "transmission loop errors". 

Upon detection of an error, the second network-independent protocol circuit may 
assume a default safety state of the I/O data. 

Thus it is another object of the invention to provide not simply for the detection of 
errors but for the defaulting of I/O data to default states as is necessary for proper safety 
operation. 

The foregoing and other objects and advantages of the invention will appear from the 
following description. In the description, reference is made to the accompanying drawings. 



which form a part hereof, and in which there is shown by way of illustration a preferred 
embodiment of the invention. Such embodiment does not necessarily represent the full scope 
of the invention, however, and reference must be made to the claims herein for interpreting 
the scope of the invention. 

BRIEF DESCRIPTION OF THE DRAWINGS 
Fig. 1 is a perspective view of a simplified industrial controller using a standard serial 
communication network linking a central controller with remote input and output circuits and 
with a remote configuration terminal, such as may be used in the present invention; 

Fig. 2 is a schematic block diagram of the control system of Fig. 1 showing redundant 
wiring from an input switch to the input circuit of Fig. 1, the input circuits having redundant 
components such as may process the signals from the input switch to send signals over the 
communication network to the controller of Fig. 1, the controller having redundant processors 
to send signals over the communications network to the output circuit of Fig. 1, the output 
circuit having redundant components to provide outputs to an actuator; 

Fig. 3 is a fragmentary view similar to Fig. 2, showing an alternative configuration of 
the input circuit of Fig. 2 using conventional control input circuits without redundant 
components; 

Fig. 4 is a fragmentary view similar to Fig. 2, showing an alternative configuration of 
the output circuit of Fig. 2 using conventional control output circuits without redundant 
components; 

Fig. 5 is a representational view of the dual communication protocols provided by the 
present invention in which data is first encoded with a safety protocol and then with a 
network protocol to be compatible with the serial network; 

Fig. 6 is a schematic representation of a data word transmitted over the standard serial 
network showing the embedding of safety formatting data with I/O data within the formatting 
provided by the standard serial network; 

Fig. 7 is a graphical representation having time on the vertical axis and distance along 
the network on the horizontal axis, showing fransmission of configuration messages to the 
input circuit, the controller and the output circuit, forming the foundation of the safety 
protocol of the present invention; 

Fig. 8 is a figure similar to that of Fig. 7 showing the transmission of messages after 
the configuration process during a start-up and run-time phase of the network; 



Fig. 9 is a block diagram of the industrial controller of Fig. 1 showing the division of 
communications between the input circuit, the controller and the output circuit into producer- 
consumer pairs such as provides redundant communication over a single network and the 
varied topologies of the implementations of Figs. 2, 3 and 4; 

Fig. 10 is a flow chart showing the principle stages of the safety protocol of 
initialization, start-up, and run-time; 

Fig. 11 is a figure similar to that of Fig. 7 showing normal protocol operation under 
the safety protocol of the present invention during run-time; 

Fig. 12 is a figure similar to Fig. 1 1 showing protocol operation with a corrupted 
producer message; 

Fig. 13 is a figure similar to Fig. 1 1 showing protocol operation with a lost producer 
message; 

Fig. 14 is a figure similar to Fig. 1 1 showing protocol operation with a corrupted 
acknowledgement message from the consumer; 

Fig. 15 is a figure similar to Fig. 1 1 showing protocol operation with a lost consumer 
acknowledgement message; 

Fig. 16 is a figure similar to Fig. 1 1 showing protocol operation with disruption of the 
connection between the producer and consumer; 

Fig. 17 is a flow chart of a program executed by the producers of Fig. 9 in 
implementing the safety protocol; and 

Fig. 18 is a flow chart of a program executed by the consumers of Fig. 9 in 
implementing the safety protocol of the present invention. 

DETAILED DESCRIPTION OF THE INVENTION 
The present invention can be part of a "safety system" used to protect human life and 
limb in the industrial environment. Nevertheless, the term "safety" as used herein is not a 
representation that the present invention will make an industrial process safe or that other 
systems will produce unsafe operation. Safety in an industrial process depends on a wide 
variety of factors outside of the scope of the present invention including: design of the safety 
system, installation and maintenance of the components of the safety system, and the 
cooperation and training of individuals using the safety system. Although the present 
invention is intended to be highly rehable, all physical systems are susceptible to failure and 
provision must be made for such failure. 



Referring now to Fig. 1, an industrial control system 10 for implementing a safety 
system with the present invention includes a controller 12 communicating on a serial network 

15 with remote input module 14 and remote output module 16. The network 15 may be a 
standard and commonly available high-speed serial network including but not limited to: 
Ethernet, DeviceNet, ControlNet, Firewire or FieldBus. The network 15 may optionally 
include a bridge 17 translating between different of the above standard or other protocols. As 
will be understood from the following, the present invention may be easily adapted to 
applications that use a bridge. 

Input module 14 may accept input signals 18 (on like-designated lines) which are 
communicated over the network 15 to the industrial controller 12. At the industrial controller 
12 the signals 18 may be processed under a control program implementing a safety system 
(such as a machine lock-out or emergency stop) and further signals sent to the output module 

16 which may produce output signals 20 (on like-designated lines) to an actuator 22. 

The input signals 18 may come from a switch 19 which may be any of a variety of 
devices producing safety input signals including but not limited to emergency stop switches, 
interlock switches, light curtains and other proximity detectors. The actuator 22 may be a 
relay, solenoid, motor, enunciator, lamp or other device implementing a safety function. 

Also connected to the network 15 is a standard computer, which may be used as a 
configuration terminal 24 whose purposes will be described below. 

Redundant System Hardware 

Referring now to Fig. 2, the switch 19 may produce redundant signals 18a and 18b 
where signal 18a is, for example, from a first contact within the switch 19, and signal 18b is 
from a second independent contact within switch 19. The contacts may have the same logic 
(as shown) both being normally open (e.g., closed with actuation of a pushbutton 26) or may 
be inverted logic with one contact normally open and one contact normally closed. In either 
case, redundant signals 18a and 18b are generated so as to provide for higher reliability in the 
determining the state of the switch 19. 

The input module 14 may include redundant interface circuitry 28a receiving signals 
18a and interface circuitry 28b receiving signal 18b. Alternatively, but not shown, interface 
circuitry 28a and 28b may each receive both signal 18a and 18b (for internal comparison) or 
may receive signals 18a and 18b from a single contact. The contacts, in generating signals 
18a and 18b, may each be provided with a separate vohage from the input circuitry 28a and 



28b or from a common voltage source (not shown). Other redundant variations on these 
wiring systems, known in the art, may also be used. 

Each of the interface circuitry 28a and 28b may in turn provide signals to associated 
microcontrollers 30a and 30b. Microcontrollers 30a and 30b provide a computer processor, 
5 memory and a stored program for executing safety protocol programs as will be described 
below. Alternatively, or in addition, the safety protocol may be executed by safety protocol 
circuits 32 with which microcontrollers 30a and 30b communicate. In this case, the safety 
protocol circuits 28a and 28b may be apphcation-specific integrated circuits (ASIC). As it is 
well known in the art to implement protocols through hardware or software or combinations 
10 of each, the term "protocol device" as used herein and in the claims should be understood to 
embrace generally any combination of software and hardware components implementing the 
indicated functions. 

: The microcontrollers 30a and 30b may communicate with each other through an 

internal bus 34 to compare signals 18a and 18b as will be described. 

"1 5 Microcontrollers 30a and 30b or safety protocol circuits 28a and 28b in turn connect 

to standard network protocol circuits 36a and 36b of a type well known in the art for handling 
the low level protocol of the standard network 15. Typically, the standard network protocol 
circuits 36a and 36b are implemented by an ASIC whose implementation represents 
considerable development time and which caimot be easily modified. 

2 0 The standard network protocol circuits 36a and 36b transmits signals from the input 

module 14 on the network 15 to be received at the controller 12 through a similar standard 
network protocol circuits 38a and 38b. These signals are processed by the standard network 
protocol circuit 38 and provided to redundant safety protocol circuits 40a and 40b, being 
similar to safety protocol circuits 32a and 32b described before. These safety protocol 

2 5 circuits 40a and 40b communicate with processors 42a and 42b, respectively, which include 

separate memory systems and control programs according to well-known redundancy 
techniques and which intercommunicate on internal bus 34'. Output signals generated by the 
processors 42a and 42b may be communicated back through the safety protocol circuits 40a 
and 40b to implement the safety protocol, as will be described below (or alternatively, the 

3 0 safety protocol may be handled by the processor 42a and 42b), and the output signals 

communicated to the standard network protocol circuits 38a and 38b for transmission again 
on network 15 to output module 16. 
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Output module 16 may receive output data through a standard network protocol 
circuit 44a and 44b being similar to standard network protocol circuits 36a and 36b and 38a 
and 38b. The standard network protocol circuits 44a and 44b provide the data to safety 
protocol circuits 46a and 46b, which in turn provide them to redundant controllers 48a and 
48b. As before, alternatively, the safety protocol may be handled by the controllers 48a and 
48b instead. The controllers 48a and 48b communicate by internal bus 34" and in turn 
provide signals to output interface circuits 50a and 50b which provide the output signals 20a 
and 20b. The output signals may be connected to the actuator 22 so that outputs must be 
enabled for the actuator 22 to be powered. In this sense, a default safety state is produced (of 
no power to the actuator 22) if there is an inconsistency between the signals received by 
processors 48a and 48b. A change in the wiring to parallel configurations could create a 
safety state where the actuator is actuated unless both signals received by processors 48a and 
48b are not enabled. 

Alternatively, and as will be described, a safety state may be enforced by a safety 
state signal transmitted from the controller 12 or the input module 14 to the microcontrollers 
48a and 48b of output module 16, the latter which may respond by producing outputs to 
output interface circuits 50a and 50b determined by stored values of desired safety states 
programmed through the configuration terminal 24 as will be described further below. 

A bridge circuit 17 per the present invention could use the basic structure shown in 
the input module 14 but replacing the interface circuitry 28a and 28b of input module 14 with 
network protocol circuits 38a and 38b and safety protocol circuits of 40a and 40b (where the 
network protocol circuits 38 and 36 are for different protocols, thereby allowing seamless 
transmission of safety data per the techniques described below). 

Referring now to Fig. 3, specialized redundant input module 14, in the present 
invention, may be replaced with two standard input modules 14a and 14b, input module 14a 
holding the equivalent of previously described interface circuitry 28a, microcontroller 30a, 
safety protocol circuit 32a and standard network protocol circuit 36a; and input module 14b 
holding the equivalent of interface circuitry 28b, microcontroller 30b, safety protocol circuit 
32b, and standard network protocol circuit 36b. In this case, the operation of safety protocol 
circuits 32a and 32b are implemented in the firmware of the microcontrollers 30a and 30b 
and effected via messages communicated on the network 15 rather than the internal bus 34. 

Likewise, referring to Fig. 4, the redundancy of output module 16 may be 
implemented by separate output circuits 16a and 16b, output module 16a including the 



equivalent of standard network protocol circuit 44, safety protocol circuit 46a, 
microcontroller 48a, and output interface circuit 50a, with output module 16b including the 
equivalents of standard network protocol circuit 44 as 44', safety protocol circuit 46b, 
microcontroller 48b, and output interface circuit 50b. As will be described below, the present 
5 invention provides a protocol that is indifferent to the exact parsing of the safety components 
among physical devices having addresses on the network 15. 

Referring now to Figs. 5 and 2, the operation of the safety protocol circuits 32 and 
standard network protocol circuits 36 in the input circuit is to embed input data 52 from lines 
1 8b within a safety-network protocol 54 implemented both as additional data attached to 
1 0 messages sent on network 15 and in the management of that data as will be described. The 
safety-network protocol 54 is in turn encapsulated in the standard network protocol 56 for 
seamless transmission on the network 15. 
-= : The S afety Network Pro toco 1 

^fi; Referring now to Figs. 5 and 2, the operation of the safety protocol circuits 32, 40 and 

y 15 46 in conjunction with the standard network protocol circuits 36, 38 and 44 is to embed I/O 
data 52 (e.g., from lines 18b) within a safety-network protocol 54 implemented both as 
additional data attached to I/O data 52 sent on network 1 5 and in the management of the 
particulars of transmission of that I/O data 52. The safety-network protocol 54 is in turn 

'J encapsulated in the standard network protocol 56 for seamless transmission on the network 

1=^0 15. 

^ The data encapsulated in the safety-network protocol 54 and standard network 

protocol 56 can then be received (e.g., by the controller 12) and extracted through the 
successive operation of the standard network protocol circuits 36, 38 and 44 and the safety 
protocol circuits 32, 40 and 46 to provide the I/O data 52 in its basic state. Note that Fig. 5 is 

2 5 only symbolic of the process and that the safety-network protocol 54 is not simply an 
encapsulation of the data 52 within for example safety data headers but rather the safety 
protocol includes timing constraints that may be executed in sequence with the standard 
network protocol 56 so that the safety-network protocol 54 may operate within the standard 
network protocol 56 without modification of the network 15 or standard network protocol 

30 circuits 36, 38 and 44. 

This dual level encapsulation and de-encapsulation is performed for each transmission 
of I/O data 52 on the network 15 that requires a high level of reliability commensurate with 
safety systems. For non-safety system data, the standard network protocol 56 may be used 
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alone without the safety-network protocol 54 for communication with non-safety elements of 
the industrial control system 10. Because all data transmitted on the network 15 is embedded 
in the standard network protocol 56, the safety-network protocol 54 will work seamlessly 
with a variety of networks 15 providing they have data transmission capacity suitable for the 
5 1/0 data 52 and sufficient in capacity to accept some added safety error detection data 58 of 
the safety-network protocol 54 as will be described. 

Safety Message Formatting 
Referring now to Fig. 6, a first aspect of the safety-network protocol 54 is that the I/O 
data 52 is attached to safety error detection data 58 to form a safety message 60 that forms the 
1 0 data provided to the standard network protocol circuits 36, 38 and 44 to produce a network 
message 61. The safety error detection data 58 may include a sequence count indicating the 
local order in which the safety message 60 is transmitted with respect to earlier transmissions 
of safety messages. The sequence count is normally limited in range (0-3) as it is intended, 
as will be described, to detect the loss of only a single message. 
1 5 Also appended to the I/O data 52 and part of the safety error detection data 58 is a 

cyclic redundancy code (CRC) selected in the preferred embodiment to be twelve-bits. The 
cyclic redundancy code is functionally generated from the I/O data 52 and the sequence count 
so that an error in the transmission of either of those data elements can be detected when the 
CRC is recalculated by the receiving device and doesn't match. As is understood in the art, a 
'2 0 twelve bit error code will allow the detection of errors with odd numbers of bit errors, all 

two-bit errors, all burst errors up to twelve bits and 99.951% of burst errors larger than twelve 
bits, for up to two-thousand and forty seven bits of data of the safety message 60. 

The safety message 60 is embedded in the network headers and footers 62 and 64, 
which vary depending on the standard network protocol 56 of the network 15. Depending on 
2 5 the network 1 5, the network header and footer 62 and 64 may include a CRC code and 

sequence count and other similar safety error detection data 58 operating redundantly with 
the safety error detection data 58. Nevertheless, the safety message 60 includes its own 
safety error detection data 58 so as to be wholly network-independent to the degree possible. 
Connected Messaging 

30 As mentioned above, the safety error detection data 58 forms only part of the safety- 

network protocol 54. The safety-network protocol 54 also includes a configuration step that 
ensures proper communication under a connected messaging scheme. Referring now to Fig. 
9, the communications between the controller 12, input module 14 (or input modules 14a and 
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14b) and the output module 16 (or output module 16a and 16b) may provide a connected 
messaging system. As is understood in the art, connected messaging involves opening a 
connection between pairs of logical devices one that acts as a "producers" of a message and 
one that acts as a "consumers" of the message. The process of opening the connection 
5 reserves bandwidth of the network and reserves necessary processing and buffering resources 
at the producer and consumer to ensure that data of the connection will be reliably 
transmitted and received. 

The connected messaging protocol may be implemented as part of the safety network 
protocol 54 or as part of the standard network protocol 56, the latter option limiting 
1 0 somewhat the types of standard networks 1 5 that may be used. Some standard network 
protocols that support connected messaging are DeviceNet and Control Net, Ethernet, and 
ATM. 

Referring now to Fig. 9, under a connected messaging protocol, the input module 14 
provides two producers 80 opening two connections with two consumers 82 of the controller 

15 12, one for each of the signals 1 8a and 18b. As a practical matter, these two connections 

mean that two separate network messages 61 will be sent over the network 15 thus decreasing 
the chance of loss of both messages. 

For the implementation of Fig. 3 with separate input module 14a and 14b, two 
producers 80 are also provided. Even though the producers 80 are now in different devices 

2 0 (having different addresses on the network 15), the operation of the control program 

implementing the safety system, above the connection level, need not changed by these 
changes in implementations. Connected messaging thus makes the safety system largely 
indifferent to topologies as providing for a natural redundancy over a single network, or 
bridging or routing across multiple links 

2 5 Controller 12 likewise includes two producers 80 exchanging data with consumers 82 

either in a single output module 16 per Fig. 2 or in separate output module 16a and 16b per 
the embodiment of Fig. 4. Two arrows are shown between each producer 80 and consumer 
82 indicating the paring of each message with an acknowledgment message under the safety 
protocol 54 as will be described below, per Fig. 9. 

30 The bridge circuit 17, not shown in Fig. 9, but as described above, would implement 

four consumers and four producers (two for each network side) as will be understood to 
those of ordinary skill in the art. 

Safety Configuration Data and Protocol 
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Referring now to Fig. 10, the safety protocol more generally includes an initialization 
state, of which the first step is developing configuration data as indicated by process block 
66. 

The configuration process involves developing configuration data at the configuration 
5 terminal 24 and ensuring that accurate copies of that configuration data are at each of the 
input module 14, the controller 12, and the output module 16. The configuration data is 
unique to each connection, provides essential components of the safety protocol, and 
identifies intercommunicating parties so as to reduce the possibility of improper connections 
injecting spurious data into the safety system. This is particularly important in allowing 
1 0 mixing of systems components observing the safety network protocol 54 with standard 

components observing only the standard network protocol. Devices may support multiple 
connections, in which case multiple configuration data specific to each connection will be 
used. 

Generally, the configuration data include data uniquely identifying the particular 
L 5 device of the input module 14, the controller 12, and the output module 16 holding the 

configuration data, and particularly the serial number of that device. The serial number is a 
unique and immutable part of the physical devices and thus together with an internal address 
of the logical devices within the physical device (which may establish independent 
connections) the serial number provides each connection with a unique identity eliminating 
2 0 the possibility of crossed connections between different devices once the configuration data is 
properly disseminated. To augment the serial number, the configuration data may also 
include a vendor identification number, a device code, a product code, major revision, minor 
revision, as well as network data including the logical, physical address of the device, all 
known in the art and identifying the particular device. Similarly, the configuration data 

2 5 within a device may include the serial number of the device to which it is connected. 

As mentioned, the connection data may also include data necessary for the 
implementation of the other aspects of the safety protocol as are yet to be described, 
including variables of "periodic time interval", "reply timer interval", "filter count", and 
"retry limit". The configuration data also includes the safety state to which the device will 

3 0 revert in the case of network error and a list of related I/O points indicating other I/O points 

(related to other connections), which should revert to the safety state if the present connection 
has an error. This later feature allows selective and intelligent disabling of the safety system 
upon a communication error as will be described. As will be evident from context, some of 
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this data, for example, data related to how particular devices should respond to a failure of 
any one device (e.g., the list of related I/O points, is dependant on the devices and their 
application and the system programmer must develop this data on an application specific 
basis. 

5 Referring to Fig. 7, configuration data held within the configuration terminal 24 is 

sent to each of the input module 14, the controller 12, and the output module 16 as messages 
66a, 66b and 66c. 

The receiving input module 14, the controller 12, and the output module 16 store the 
configuration and respond with the same configuration message but changed to a one's 
1 0 complement form (being simply a different binary coding (the inversion)) of the 

configuration data received. This one's complement message is returned by messages 66d, 
66e, and 66f from the respective input module 14, the controller 12, and the output module 
16. If the configurations of messages 66a, 66b and 66c exactly match (after complementing) 
configuration data of messages 66d, 66e and 66f, the configuration was successful. 
; ' 1 5 The configuration data may be shown to a human operator for confirmation. If the 

=: operator finds that the configuration is correct, the configuration is applied as indicated by 

' process 68 shown in Fig. 10 through messages 68a, 68b and 68c from the configurafion 

terminal 24 to the respective input module 14, the controller 12, and the output module 16. 
The devices must acknowledge these messages via messages 68d, 68e and 68f within a 
lT:2 0 predetermined time interval or the configuration will be cleared and no configuration will be 
-: considered to have occurred. The configuration data of messages 66 and 68 may be sent 

using only the standard network protocol 56. 

Once the configuration is complete, the safety protocol enters a start-up phase shown 
generally in Figs. 8 and 10. During the start-up phase, the necessary safety connections are 
2 5 established and the configuration data is used to verify that the connections expected are 
those which are in fact made. The purpose of the start-up portion of the configuration is to 
prevent erroneous connections fi-om being opened between: (1) devices in the safety system 
and other erroneous devices in the safety system, and (2) devices in the safety system and 
other devices not in the safety system in a mixed system. 
30 In this start-up process, indicated by process block 70 of Fig. 10, the connections are 

confirmed from the controller 12 to the input module 14 and the output module 16. In 
particular, the producers 80 in controller 12 (shown in Fig. 9) send out open connection 
messages 70a and 70b to the input module 14 and the output module 16, respectively. The 
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appropriate consumers 82 respond with connection acknowledgment message 70c and 70d, 
respectively. The producers 80 in controller 12 and input module 14 then send the 
configuration data to the consumer 82 in the controller 12 as indicated by messages 70e and 
70f. The controller's consumers 82 check to see that the configuration data matches their 
5 configuration data and then send acknowledgment messages 70f and 70g acknowledging that 
match. At messages 72a and 72b, conventional I/O data may then commence to be sent. 

Referring again to Fig. 10, the data 72a and 72b will be transmitted according to the 
portions of the safety protocol indicated by process blocks 72 involving formation of the 
safety message 60 incorporating safety error detection data 58 into the network message 61 as 
1 0 has been described above, and according to message handling protocols 74 operating 

independent of and in conjunction with the content of the safety message 60 which will now 
be discussed. 

Message Handling Safety Protocols 
( 1 ) Normal Transmission 
1 5 Referring generally to Figs. 10 and 1 1, the message handhng protocols 74 provide for 

message time measurements and respond to errors in the safety error detection data 58 during 
run-time. These message-handling protocols 74 are implemented in the safety protocol 
circuits 32, 40 and 46 or may be implemented in software and are different for producers and 
consumers. 

2 0 Referring now to Figs. 1 1 and 1 7 for a normal, run-time transmission, the producer 80 

upon run-time will send safety messages 84 (encapsulated in the standard network message 
61 per safety message 60 as has been described above) to the consumer 82 per Fig. 11. This 
sending is indicated generally in Fig. 17. Immediately prior to sending the message 84, a 
periodic timer is started per process block 89 and a reply timer is started at the moment the 

2 5 message 84 is transmitted per process block 91 . The periodic timer interval 86 is longer than 

the reply timer interval 88 as set in the configuration process described above. 

Referring now to Fig. 9, 1 1 and 18, the consumer 82 prior to receiving the message 84 
is continually checking to see if the periodic time interval 86' of its own periodic timer 
(started at the consumer's receipt of the last message 84) has expired as indicated in decision 

3 0 block 92. The periodic timer value 86' is generally greater than periodic timer value 86. 

If the periodic timer has expired, a failure is indicated and the program proceeds to 
process block 134, a safety state, as will be described below. 



16 



If timer value 86 has not expired, then at decision block 90, the consumer 82 checks 
to see if the message 84 has arrived. If no message 84 has arrived the program proceeds back 
to decision block 92 to again check if the periodic timer 86 has expired. 

Assuming that a message 84 has arrived prior to expiration of the periodic timer 86, 
5 then the program proceeds to decision block 112 to check the CRC of the message 84. 

Assuming that the CRC is correct, the program proceeds to decision block 96 and 
checks to make sure that the sequence count is one greater than the sequence count of the last 
message received. 

If the sequence count is correct, then the program proceeds to process block 94 and 
1 0 the periodic timer 86 is reset. At process block 95, the data is apphed, for example, to an 

output or to update variables, and then at process block 98, an acknowledgment messagelOO 
is returned to the producer 80. 

Referring again to Fig. 17, the producer 80 receiving the acknowledge message at 
decision block 102, proceeds to decision block 106 to determine if the periodic timer 86 has 
1 5 expired. 

Assuming that the periodic timer has not expired, the program proceeds to decision 
block 124 to check the CRC of the acknowledgement message 100. The cyclic redundancy 
code should match the data of the safety message 60 transmitted. 

Again, assuming that the CRC is correct, the program proceeds to decision block 125 
2 0 to determine whether the sequence count of the acknowledgment message 100 matches that 
of the message 84 that was sent. 

If so, then at decision block 127, the data sent in message 84 is compared to the data 
of the acknowledgement message 100. If there is a match, then the program proceeds to 
decision block 129 where it loops until the periodic timer has expired, and then proceeds to 

2 5 process block 1 1 0 to prepare a new message 84. 

This process is repeated for multiple transmissions of safety messages 84 and 
acknowledgement messages 100. 

(2) Message Received but Corrupted 

Referring now to Fig. 11 in one potential error the safety message 84 is corrupted for 

3 0 example by electromagnetic interference 85. In this case a message is received at the 

consumer 82, as indicated by Fig. 18 per process block 90, within the periodic timer value 86' 
as measured by process block 92 however there is an error in the CRC data as determined by 
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decision block 112. In this case, the program proceeds to process block 114 and no action is 
taken and in particular no acknowledgement message 100 is returned. 

Referring to Fig. 17, in this case there will be no acknowledgment message 100 
received by the producer 80 at process block 102. The program proceeds to decision block 
5 1 16 to determine if the periodic time interval 86has expired. If so, the failure is indicated and 
the program proceeds to the safety state of process block 126. 

If the periodic timer interval 86 has not expired, the program will proceed to decision 
block 118 to see if the shorter reply timer interval 88 has expired. If not, the program will 
loop back to process block 102. If so, the program will proceed to process block 120 to 
1 0 check if the retry limit has been exceeded. Initially this may not be the case and the program 
will proceed to process block 122 and a repeat message 84' having the same sequence count 
will be sent at process block 84, as also indicated by Fig. 12. If the retry hmit has been 
exceeded, the program proceeds to the safety state 126. 

This repeat message 84' will be received at the consumer 82 as indicated by process 
1 5 block 90 of Fig. 1 8 and assuming that it is correct it and that it has arrived within the periodic 
timer interval 86' based on the previous non-erroneous message, this message 84' results in 
the sending of an acknowledgment message 100 at process block 98 per the steps described 
above. 

Typically, if only one missed transmission has occurred, the acknowledgment 
2 0 message 100 will occur within the periodic timer interval 86 of the producer and messages 
will be continued to be exchanged normally as has been previously described with respect to 
Fig. 11. 

(3) Message Not Received 

Referring now to Fig. 13, in the previous example, the safety message 84 arrived at 
2 5 the consumer 82 to be detected, albeit with errors. It is possible that the safety message 84 
will not arrive at the consumer 82 either as a result of such extreme interference that it is not 
recognizable as a message under low level network protocols, or as a result of component 
failures between the producer and the consumer of an intermittent nature. Under this 
situation, the producer 80 sends the message 84 but the consumer does not receive a message 
30 at process block 90 of Fig. 18. 

The "no action" block 1 14 of Fig. 18 of the consumer (as described above) is thus not 
encountered but the result is in any case the same: the consumer 82 takes no action. 
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Thus, as described previously with respect to Fig. 12 at the expiration of the reply 
timer at the producer 80, the producer 80 will produce a second message 84' which if 
received will result in an acknowledgment message 100 initiating a string of normal 
communications. 

(4) Acknowledgement Message Received but Corrupted 

Referring now to Fig. 14 the safety message 84 may successfully reach the consumer 
82 with no errors but the acknowledgement message 100 may have errors introduced by 
electromagnetic interference 85. In this case the producer 80 reacts as shown in Fig. 17 by 
decision block 106 to detect a receipt of an acknowledgment message 100 within the periodic 
timer interval 86. But there is an error in the data of the acknowledgment message 100. 

If the CRC is correct as determined by decision block 124 and it is the sequence count 
that is wrong per process block 124, then the program enters the safety state 126 in which 
outputs and inputs of the consumer 82 are set to a predefined safety state of the configuration 
data. Similarly, if the sequence count is correct but the acknowledgement data does not 
match per decision block 127, the program proceeds to the safety state 126. If the consumer 
82 is the controller 12 messages may be sent to other I/O devices, indicated in the 
configuration data signaling them to move to the safety state as well. 

Assuming at process block 124 that the CRC code does not match the safety message 
60. indicating a corruption in the safety message rather than an erroneous duplicate message, 
the program proceeds to decision block 118 to see if the reply timer has expired as described 
above. When the reply timer expires the program proceeds to process block 120 as described 
above and checks the retry counter to see if the retry limit has been exceeded. If so, the 
program proceeds to the safety state 126 however often this will not have occurred and the 
program proceeds to process block 122 and a retry message 84' is prepared as indicated in 
Fig. 14. 

Assuming this retry message evokes a non-corrupted acknowledgment message 100' 
communication continues in normal fashion. 

(5) Acknowledgement Message Not Received 

Referring now to Fig. 15 it is possible that the acknowledgment message 100 is lost 
completely either through interference or temporary communication failure. In that case, as 
has been previously described, a duplicate message 84 will be sent from the producer 80 
however the sequence count will be identical to the sequence count of a message 84 
previously received by the consumer 82. In this case as shown in Fig. 18 at process block 
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1 12 the CRC will be correct but as tested at subsequent decision block 96 the sequence code 
will be wrong. The program, in this case, proceeds to process block 130 to check if the 
sequence code is one less than that expected. If not the program proceeds to the safety state 
134. If so, however, the consumer 82 must conclude that the acknowledgment message 100 
5 was lost and an acknowledgment of the previous message is sent again by the consumer at 
process block 132. 

(6) No Messages Received 

Finally as shown in Fig. 15 the producer may be unable to connect with the consumer 
within the periodic interval 86' of the consumer. In that case the program proceeds to the 
1 0 safety state 1 34 directly from decision block 92 as shown in Fig. 1 8 . 

The above description has been that of a preferred embodiment of the present 
invention, it will occur to those that practice the art that many modifications may be made 
without departing from the spirit and scope of the invention. In order to apprise the public of 
the various embodiments that may fall within the scope of the invention, the following claims 
1 5 are made. 
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WE CLAIM: 



CLAIMS 



1 . A network-independent, high-reliability communications system for an 
industrial controller using a standard serial communications network, the communications 
system comprising: 

a first I/O communications circuit receiving I/O data for control of an industrial 
5 process; 

a first network-independent protocol device receiving the I/O data and formatting 
it for transmission under a network-independent protocol to produce high-reliability 
formatted data formatted to reduce undetected transmission loop errors; 

a first standard network protocol device receiving the high-reliability formatted 
1 0 data and further formatting it for transmission under a protocol of the standard serial 
communications network, to produce doubly-formatted data for transmission on the 
standard serial communications network, the protocol of the standard serial 
communications network also formatting data to reduce undetected transmission loop 
errors; 

15 a second standard network-protocol device receiving the doubly-formatted data 

from the standard serial communications network and extracting the high-reliability 
formatted data according to the protocol of the standard serial communications network; 

a second network-independent protocol device receiving the high-reliability 
formatted data and extracting the I/O data; and 
2 0 a second I/O communications circuit receiving I/O data for control of an industrial 

process from the second network-independent protocol device; 

whereby high-reliability transmissions may be simply obtained on an arbitrary 
standard serial communications network protocol. 

2. The industrial controller of claim 1 wherein the first and second I/O 
communications circuits are selected from the group consisting of an industrial controller, 
an input circuit for an industrial controller, a bridge, and an output circuit for an industrial 
controller. 
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3. The industrial controller of claim 1 wherein the first network-independent 
protocol device formats the I/O data by adding error detection data consisting of: a cyclic 
redundancy code related to the I/O data and a sequence count related to a local order of 
transmission of the I/O data with respect to other I/O data being transmitted. 

4. The industrial controller of claim 1 wherein the second network-independent 
protocol device further generates an acknowledgment message upon receipt of the I/O 
data and formats it under the network-independent protocol to produce a high-reliability 
formatted acknowledgment data; 

5 and wherein the second standard network protocol device receives the high- 

reliability formatted acknowledgment data and further formats it for transmission under 
the protocol of the standard serial communications network, to produce doubly-formatted 
acknowledgment data for transmission on the standard serial communications network; 
and wherein the first standard network-protocol device receiving the doubly- 
1 0 formatted acknowledgment data from the standard serial communications network and 
extracts the high-reliability formatted acknowledgment data according to the protocol of 
the standard serial communications network; 

and wherein the first network-independent protocol device receiving the high- 
rehability formatted acknowledgment data checks the data to detect transmission loop 
1 5 errors. 

5. The industrial controller of claim 4 wherein the acknowledgment data includes 
the I/O data and the first network-independent protocol device detects errors by 
comparing the I/O data to the acknowledgment data. 

6. The industrial controller of claim 1 wherein the first network-independent 
protocol device operates to start a timer upon receipt of the I/O data and wherein the first 
network-independent protocol device detects errors by checking a time on the timer 
against an allowable time upon receipt of the acknowledgment message. 

7. The industrial controller of claim 1 wherein the first network-independent 
protocol device transmits I/O data on a regular interval and wherein the second network- 
independent protocol device detects errors by comparing the time at which the last I/O 
data was received against the time interval. 
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8. The industrial controller of claim 1 wherein the second network-independent 
protocol device evaluates the high-reliability formatted data to detect transmission loop 
errors of the I/O data and upon the detection of an error for I/O data assume a default 
safety state of the I/O data. 

9. The industrial controller of claim 4 wherein the first network-independent 
protocol device evaluates the high-reliability formatted data to detect transmission loop 
errors of the I/O data and upon the detection of an error for I/O data assume a default 
safety state of the I/O data. 

10. The industrial controller of claim 1 wherein the standard serial 
communications network is selected from the group of networks consisting of Ethernet, 
DeviceNet, ControlNet, Fire Wire and Field Bus. 

11 . A method of providing a high-rehability communications system for an 
industrial controller using a standard serial communications network, the communications 
system comprising the steps of: 

(a) receiving I/O data for control of an industrial process at a first I/O 
communications circuit; 

(b) formatting the received I/O data for transmission under a network-independent 
protocol at a first standard network protocol device to produce high-reliability formatted 
data formatted to reduce undetected transmission loop errors; 

(c) receiving the high-reliabihty formatted data at a first standard network 
protocol device and further formatting it for transmission under a protocol of the standard 
serial communications network, to produce doubly-formatted data for transmission on the 
standard serial communications network, the protocol of the standard serial 
communications network also formatting data to reduce transmission loop errors; 

(d) receiving the doubly-formatted data from the standard serial communications 
network at a second standard network-protocol device and extracting the high-reliability 
formatted data according to the protocol of the standard serial communications network; 

(e) receiving the high-reliability formatted data at a second network-independent 
protocol device and extracting the I/O data; and 

(f) receiving I/O data for control of an industrial process from the second network- 
independent protocol device at a second I/O communications circuit; 



whereby high-reliability transmissions may be simply obtained on an arbitrary 
standard serial communications network protocol. 

12. The method of claim 1 1 wherein at step (b) the first network-independent 
protocol device formats the I/O data by adding error detection data selected from the 
group consisting of: a cyclic redundancy code related to the I/O data and a sequence 
count related to a local order of transmission of the I/O data with respect to other I/O data 
being transmitted. 

13. The method of claim 1 1 including the further steps of: 

(e) generating a reply message by the second network-independent protocol 
device upon receipt of the I/O data formatted under the network-independent protocol to 
produce a high-reliability formatted acknowledgment data; 

(f) receiving the high-reliability formatted acknowledgment data at the second 
standard network protocol device and further formatting it for transmission under the 
protocol of the standard serial communications network, to produce doubly-formatted 
acknowledgment data for transmission on the standard serial communications network; 

(g) receiving the doubly-formatted acknowledgment data from the standard serial 
communications network at the first standard network-protocol device and extracting the 
high-reliability formatted acknowledgment data according to the protocol of the standard 
serial communications network; and 

(h) receiving the high-reliability formatted acknowledgment data at the first 
network-independent protocol device to detect transmission loop errors. 

14. The method of claim 13 wherein the acknowledgment data reflects the I/O 
data and wherein at step (h) the first network-independent protocol device detects errors 
by comparing the I/O data to the acknowledgment data. 

15. The method of claim 1 1 wherein at step (b) the first network-independent 
protocol device starts a timer upon receipt of the I/O data and wherein at step (h) the first 
network-independent protocol device detects errors by checking a time on the timer upon 
receipt of the acknowledgment message. 



16. The method of claim 1 1 wherein at step (b) the first network-independent 
protocol device transmits I/O data on a regular interval and wherein at step (e) the second 
network-independent protocol device detects errors by comparing the time at which the 
last I/O data was received against the time interval. 

17. The method of claim 1 1 wherein at step (e) the second network-independent 
protocol device uses the formatting of the first network-independent protocol device to 
detect transmission loop error in transmission of the I/O data, and upon the detection of 
an error for I/O data to assume a default safety state of the I/O data. 

18. The method of claim 13 wherein the first network-independent protocol 
device evaluates the high-reliability formatted data to detect transmission loop errors of 
the I/O data and upon the detection of an error for I/O data assume a default safety state 
of the I/O data. 

19. The method of claim 1 1 wherein the standard serial communications network 
is selected trom the group of networks consisting of Ethernet, DeviceNet, ControlNet, 
Fire Wire and Field Bus. 
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ABSTRACT OF THE INVENTION 
A highly reUable industrial control system is produced using a network running a 
standard serial protocol. A safety protocol is embedded within the standard serial 
protocol by adding to special error detecting data redundant with the protocol of the 
standard serial network. In addition an overarching protocol involving timing of 
messages is imposed to provide the necessary level of reliability in the standard serial 
network. This approach allows the safety protocol to be used with a wide variety of 
commercially available serial communication standards without modification of the 
media or the specialized integrated circuits used for that communication. Safety protocol 
may be implemented in an additional level for integrated circuits or through firmware 
changes in programmable aspects of the industrial controller components. 
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foreign application for patent or inventor's certificate having filing date before that of the application 
on which priority is claimed: 

Prior Foreign Application(s) 



(Application No.) (Country) (Filing Date) 

I hereby claim the benefit under Titie 35, United States Code, §1 19(e) of any United States 
provisional application(s) listed below 

60/171,439 _US 12/22/1999 

(Application No.) (Counfay) (Filing Date) 

I hereby claim the benefit under Title 35, U.S.C., § 120 of any United States application(s), or 
§365(c) of any PCT International application designating the United States, listed below and, insofar 
as the subject matter of each of the claims of this application is not disclosed in the prior United States 
or PCT International application in the manner provided by the first paragraph of 35 U.S.C. § 112, 1 
acknowledge the duty to disclose information which is material to patentability as defined in 37 CFR 
§ 1 .56 which became available between the filing date of the prior application and the national or 
PCT International filing date of this application. 



(Application Serial No.) Filing Date) (Status-patented, pending, abandoned) 
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I hereby appoint the following attomey(s) and/or agent(s) to prosecute this application and to transact 
all business in the Patent and Trademark Office connected therewith: 



Keith M. Baxter - Reg. No. 31,233 Michael A. Jaskolski - Reg. No. 37,551 

William R. Walbrun - Reg. No. 37,464 Steven J. Wietrzny - Reg. No. 44,402 

Alexander M. Gerasimow Reg. No. 28,610 ^ 

John J. Horn - Reg. No. 28,803 

Address all telephone calls to : 

John J. Horn at telephone number (414) 382-3561 

Address all correspondence to : 

Rockwell Technologies, LLC 

Attention: John J Horn 

Patent Dept./704P Floor 8 T-29 

1201 South Second Street ^ 

Milwaukee, Wisconsin 53204 . _ 

I hereby declare that all statements made herein of my own knowledge are true and that all statements 
made on information and belief are believed to be true; and further that these statements were made 
with the knowledge that willful false statements and the like are punishable by fine or imprisonment, 
or both, under Section 1001 of Title 18 of the United States Code and that such willful false 
statements may jeopardize the validity of the application or any patent issued thereon. 



Full name of first inventor Kerry W. Vandesteeg 

Inventor's Signature ^^y^y fAi^ AL^H^ J^ate b/zT? / 

Citizenship U.S. 
Residence Chagrin Fall; 



■all^Ohio 



Post Office Address 75 West Bellmeadow, Chagrin Falls, Ohio 44022 



Full name of second inventor David A. Vasko 

Inventor's Signature cJhr.^ CL. V^Ut^ Date g A-yAooo 

Citizenship U.S. . . 

Residence Macedonia, Ohio . 



Post Office Address 9480 Woodview Drive, Macedonia, Ohio 44056 



2 



Full name of third inventor Joseph A. Lenner 



Inventor's Signature Mr^x^ ^^^^^t^ Date Sl hi 

Citizenship U.S. ~1/ ^ .y^ ' ' ' ^ 



Citizenship 
Residence Hudson, Ohio 



Post Office Address 7578 Bendleton Drive, Hudson, Ohio 44056 



Full name of fourth inventor Kenwood H. Hall 

Inventor's Signature ^^--''^y^^^^ j^^^"^ Date ^/ZJ/gr^j 

Citizenship U.S. ^ - - - 

Residence Hudson, Ohio 



Post Office Address 1768 East Sapphire Drive, Hudson, Ohio 44236 
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